The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
A Symmetric Multi Processor (SMP) machine, or box, is a multiprocessor computer host in which two or more Central Processing Units (CPUs), or processors, are operatively connected to a single shared physical memory and are controlled by a single Operating System (OS) instance. Typically, large organizations deploy multiple database instances on the same SMP host in order to improve utilization and to reduce the total cost of ownership (TCO). Because of the high TCO of SMP hosts, many organizations would like to additionally achieve clustered scalability from such multi-tenancy deployments of database instances on SMP hosts. Unfortunately, however, clustered multi-tenancy deployments are not widely used because they suffer from an inability to share physical memory among the multiple database instances that run on the same SMP host.
Specifically, clustered scalability is difficult to achieve in multi-tenancy deployments because of an over-provisioning of physical memory. For example, while an SMP host may have 4-8 CPUs that share one or more terabytes of physical memory, in typical deployments there may be twenty or even more database instances that run simultaneously on the SMP host. To address the memory requirements of so many database instances, administrators are typically forced to configure all of the available physical memory of the SMP host among the various database instances. However, when one or some of the database instances start experiencing a heavier workload than the others, it is not possible for the OS instance on the SMP host to allocate more physical memory to these database instances because all of the physical memory of the SMP host has already been provisioned. In order to address this over-provisioning problem, administrators typically have to shut down one or several database instances that are not busy at the time, so that the OS instance on the SMP host can re-provision the released physical memory to the database instances that are experiencing the heavy workloads. Needless to say, this solution is not only inefficient because it involves intervention by administrators, but it also lacks the consolidation desired from the multi-tenancy deployment on the SMP host because when database instances are shut down they are not available for failover and any other availability purposes. Further, under such multi-tenancy deployments, it is clear that the problem of memory over-provisioning is a serious obstacle to achieving real scalability by deploying multiple database instances in one or more clusters.
While the problem of memory over-provisioning is described above with respect to database instances that are deployed on SMP hosts, it is noted that this problem is not unique to SMP hosts or to database instances. Rather, the same memory over-provisioning problem may be experienced in multi-tenancy deployments on smaller commodity server machines for any type of data-processing instances that use a lot of volatile memory to buffer data from persistent storage in order to access and modify the data before writing it back to the persistent storage.